home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / ietf / wg_guide.txt < prev    next >
Text File  |  1993-02-17  |  12KB  |  269 lines

  1.  
  2.         Guidelines to Working Group Chair(s)
  3.  
  4. Formation
  5. ---------
  6.  
  7. IETF working groups are the primary mechanism for the development of
  8. IETF protocols, standards, and recommendations.
  9.  
  10. Before any working group is created, some preliminary work must be
  11. done.  First, anyone interested in creating an IETF working group must
  12. consult with the appropriate IETF Area Director under whose direction
  13. the working group would fall, to confirm that creating a working group
  14. is appropriate.
  15.  
  16. When determining if creating a working group is appropriate, the Area
  17. Director will consider several issues:
  18.  
  19.    o Does the working group's activities overlap with those of another
  20.      working group?  If so, it may still be appropriate to create
  21.      another working group, but this question must be considered
  22.      carefully.  Subdividing efforts often dilutes the available
  23.      technical expertise.
  24.  
  25.    o Are there several people clearly interested in the working group's
  26.      topic and willing to expend the effort to produce a result (such as
  27.      an RFC)? There are situations where, while the problem the working
  28.      group would tackle is interesting, there are not motivated bodies
  29.      to make a working group effective.  Working groups require
  30.      considerable manpower:  a chairman is needed to run meetings, an
  31.      editor to edit authors' submissions, and authors to actually write
  32.      text.  IETF experience suggests that these roles typically cannot
  33.      all be handled by one person, four or five active members are
  34.      typically required.  If the necessary manpower is lacking, the
  35.      person interested in creating the working group might consider
  36.      actually writing the RFC alone (an activity which usually is
  37.      feasible), and then submitting it to the IETF for review, rather
  38.      than creating a working group.
  39.  
  40.    o Are the issues that the working group plans to address important?
  41.      Usually, if the issues are not important, then the necessary
  42.      manpower will not exist, but the question is worth considering
  43.      separately.
  44.  
  45. The Area Director, considering the above criterion will decide whether
  46. to pursue the formation of the group through the chartering process.
  47.  
  48.  
  49. The Charter
  50. -----------
  51.  
  52. The formation of a working group requires an approved, written
  53. charter.  This work statement should in about one page explain the
  54. general purpose of the group, delimit its technical scope, enumerate a
  55. set of goals and milestones together with timeframes for their
  56. completion, and document various administrative points.
  57.  
  58. The content of the charter document is negotiated between a
  59. prospective working group chair and the relevant area director.  When
  60. both the prospective working group chair and the area director are
  61. satisifed with the charter text, it can become the basis for forming a
  62. working group. The charter document may be similarly renegotiated at
  63. any time during the course of the working group's effort to reflect
  64. the changing goals of the group.
  65.  
  66. Each charter consists of 5 sections.  These sections include both
  67. static information about the group, the name, the chairmen, the
  68. mailing lists, and the description.  The goals and milestones are part
  69. of the IETF tracking system, and are designed to allow a degree of
  70. project management and support.  They change periodically to reflect
  71. the current status of the group.
  72.  
  73.    o Name:  A working group name should be reasonable descriptive.
  74.      Additionally the group needs to find an 8 character ASCII acronym
  75.      to reference the group in the IETF directories, mailing lists, and
  76.      general documents.
  77.  
  78.    o Chair(s):  The working group may have one or two chair(s) to
  79.      perform the administrative functions of the group.  It is strongly
  80.      suggested that these persons have internet mail addresses.
  81.  
  82.    o Mailing Lists:  Most of the work of an IETF working group is
  83.      conducted on Internet Mail exploder lists.  It is required that an
  84.      IETF working group have a general discussion list.  A person needs
  85.      to be designated the list service postmaster, usually through the
  86.      list-request alias.  An archive should be maintained in a publicly
  87.      FTPable place.  The IETF-archive@cnri.reston.va.us should be added
  88.      to the mailing list.  
  89.  
  90.      It is strongly recommended that the mailing list be on an
  91.      connected IP host, to facilitate use of the SMTP  expansion
  92.      command (EXPN) and to allow FTPaccess to the mail archives. If
  93.      this is not possible, the archive and membership of the list must be
  94.      made available by querying the list-request alias.
  95.  
  96.    o Description:  In 1-2 paragraphs, the focus and intent of the group
  97.      should be set forth.  By reading this section alone, a person
  98.      should be able to decide whether this group is relevant to their
  99.      work.  
  100.  
  101.      Recognising the importance of security and network management in the
  102.      Internet Architecture, this description of the work of the group must
  103.      specifically address the impact in terms of security and management.
  104.  
  105.    o Goals and Milestones:  The working group should after the first
  106.      meeting be able to enumerate a timetable for work.  While this
  107.      often will change, it is indispensable to potential participants to
  108.      be able to identify the critical moments for input.  This milestone
  109.      list should be updated periodically to reflect progress.  Updated
  110.      milestones should be submitted along with meeting minutes.
  111.  
  112.      Goals should be trackable items.  It is strongly recommended that
  113.      each document the Working Group intends to produce be listed both
  114.      with a date the first draft is expected to be installed as an 
  115.      Internet Draft, and the date the Working Group intends to send
  116.      the document to the IESG.
  117.  
  118.  
  119. Announcement of the Group
  120. -------------------------
  121.  
  122. After a charter is written, it should be submitted to Greg Vaudreuil
  123. <gvaudre@ri.reston.va.us> for recording.  He will enter the chartering
  124. information into the IETF tracking database and send the charter to
  125. the IESG-TECH mailing list for approval and comment.  Upon approval of
  126. the charter, the Vaudreuil will send the charter to the IETF mailing list.
  127.  
  128. Duties of the Working Group Chair(s)
  129. ------------------------------------
  130.  
  131. The working group chair(s) have wide discretion in the conduct of
  132. business.  The working group chair(s) have the responsibility to call
  133. meetings of the working group, to make reports of the working group
  134. activity available for public distribution, and otherwise advance the
  135. group toward completion of the goals of the group as listed in the
  136. charter.
  137.  
  138. Scheduling of Meetings
  139. ----------------------
  140.  
  141. The working group is expected to meet periodically to discuss and direct
  142. future progress.  It is expected, but not required that every working
  143. group meet at the trimester IETF plenary sessions.  Additionally,
  144. interim meetings are encouraged by telephone conference, video
  145. teleconference, or by actual face to face meetings.  Meetings should be
  146. publicized as widely as possible, by announcing their time and location
  147. on the working group mailing list, the IETF mailing list, and by putting
  148. the date on the IETF Calendar by notifying Megan Davies
  149. <mdavies@cnri.reston.va.us>.
  150.  
  151. Meeting Policy
  152. --------------
  153.  
  154. All working group actions should be public, and wide participation
  155. should be encouraged.  An announcement of the date and time must be
  156. sent to the working group mailing list and to Megan Davies
  157. <mdavies@cnri.reston.va.us> a reasonable time before the meeting.
  158.  
  159. After a period of open meetings, the working group chair may hold
  160. executive (closed) meetings of the working group consisting of the
  161. authors of a particular document and any serious reviewers.  This is
  162. often necessary to make forward progress preparing a final document.
  163. All work conducted in executive session must be made available for
  164. review by any interested party.
  165.  
  166. Preparation of Minutes
  167. ----------------------
  168.  
  169. All working group sessions should be reported by making minutes
  170. available.  It is expected that the working group chair(s) (or a
  171. person designated by the working group chairman) submit minutes in
  172. ASCII text to Megan Davies <mdavies@cnri.reston.va.us> after each
  173. meeting for publication in the IETF Proceedings, and for posting in
  174. the IETF Directories.
  175.  
  176. These minutes should include the agenda for the meeting, an account of
  177. the discussion including any decisions made, and a list of attendees.
  178.  
  179. Document Authorship
  180. -------------------
  181.  
  182. The work of an IETF working group usually results in the publication of
  183. one or more RFC's.  This series of documents are the journal of record
  184. for the internet community.  A document can be written by an individual
  185. in the working group or by the group as a whole with a designated
  186. editor.  The designated author need not be the group chair(s).
  187.  
  188.  
  189. Internet Drafts
  190. ---------------
  191.  
  192. The Internet Drafts directories are provided to the working groups as
  193. a resource to post and disseminate early copies of any and all
  194. documents of the working group.  This common repository is available
  195. to all interested persons to facilitate wide review and comment.  It
  196. is encouraged that draft documents be posted as soon as they become
  197. reasonably stable.  Posting after they are in their final form reduces
  198. the utility of this resource.  See the ``Guidelines to Authors of
  199. Internet-Drafts'' for a more complete description and some basic
  200. guidelines.
  201.  
  202. Termination of a Working Group
  203. ------------------------------
  204.  
  205. Working groups are typically chartered to accomplish a specific task.
  206. After that task is complete, the group will be disbanded.  If after a
  207. meeting a few times, it becomes evident that the group is unable to
  208. complete the work outlined in the charter, the group with it's area
  209. director can either 1) recharter to refocus on a smaller task, 2)
  210. choose new chair(s), or 3) disband.
  211.  
  212. In those situations where the working group chairperson and the area
  213. director disagree about the steps required to refocus the group or the
  214. need to disband the group, the IESG will make a determination with
  215. input from the area director and the working group chair(s)
  216.  
  217.  
  218.  
  219. Sample Charter
  220.  
  221. Internet Thumb Twiddling Protocol Working Group (ittp)
  222.  
  223. Chair(s):
  224.  
  225.      Jolly Goodtimer/ABC Jolly_G@abc.washington.dc.us
  226.  
  227. Mailing Lists:
  228.      General Discussion:  ittp@abc.washington.dc.us
  229.      To Subscribe:  ittp-request@abc.washington.dc.us
  230.      Mail Archive:  pub/ittp-archive@abc.washington.dc.us
  231.  
  232. Description of Working Group:
  233.  
  234.      The Internet Thumb Twiddling working group is chartered to
  235.      define a protocol for remotely twiddling thumbs over the
  236.      Internet.  In defining this protocol, several questions must be
  237.      addressed.  The use of remote or virtual thumbs must be more
  238.      clearly defined.  The widespread usage of this protocol may
  239.      generate large amounts of traffic, and the impact of such
  240.      traffic needs to be analyze.  As with all modern protocols,
  241.      provisions also must be made for the remote management of the
  242.      protocol, as well as of the thumbs, and for authenticated
  243.      twiddling.  Other security issues will be considered, but do
  244.      not seem a priority at this time.  However, there might be a
  245.      need to limit participant embarrassment at being a thumb
  246.      twiddler, so that additional mechanisms will be needed to
  247.      prevent disclosure.
  248.  
  249. Goals and Milestones:
  250.  
  251. May 1999      First IETF Meeting:  review and approve the charter
  252.               making any changes deemed necessary.  Examine the
  253.               particular functional needs for a TT protocol and define
  254.               the scope of the service.  Begin work on a framework for
  255.               the solution, if non-trivial.  Assign writing assignments
  256.               for first draft of document.  First draft to be
  257.               completed.
  258.  
  259. Sep 1999      Review first draft document, determine necessary
  260.               revisions.  Follow up discussion will occur on mailing
  261.               list.
  262.  
  263. Dec 1999      Make document an Internet Draft.  Continue revisions
  264.               based on comments received at meeting and over e-mail.
  265.  
  266. Mar 2000      Fourth IETF meeting.  Review final draft and if OK, give
  267.               to IESG for publication as RFC. Begin implementations.
  268.  
  269.